Machine vision systems are used in a wide range of manufacturing processes. Among other uses, machine vision is employed to ensure quality and to assist in the constructing various articles and devices. A common use for vision systems in industrial applications is in association with an inspection or assembly location on a moving production line. Images of objects are acquired as they pass under the vision system camera's field of view. Based upon image data acquired, the vision system can decide whether there is a flaw in the object, determine its alignment for further processes, operate a robot manipulator, identify and sort the object into an appropriate bin, or perform other automated tasks.
In a typical implementation, the triggering of image acquisition by the vision system is performed according to an external modality. For example, the drive system for the moving line can include an encoder that triggers after a certain number of pulses that are associated with line movement. Likewise a photoeye/photodetector can be used to sense the presence of an object arriving at the field of view. The camera receives a trigger signal from the photoeye to acquire the image at this time. This approach entails additional hardware and has limited ability to modify the conditions for triggering. Such modifications can be desirable in certain applications—for example, where a photoeye cannot be conveniently mounted near the field of view, or has a disadvantageous view of the object.
Some vision systems provide a native image-triggering mode within the camera assembly. However, even when a system has such a native image triggering mode, that mode is typically very rigid such that if a user desires to apply even a slight change to the trigger mode, the system's software would most likely require a change and/or upgrade. This is because the parameters used to change the image trigger mode are typically not exposed to the user in an interface that he or she can access and control. Even if there are parameters exposed to configure the image trigger mode in available vision systems, those parameters are finite and fixed. The user would not, for example, be able to arbitrarily add a filter to the image trigger.
By way of background and definition, a “trigger event” is generally defined as a circumstance in which the system is instructed to acquire an image for inspection. In the case of an external source, such as a photo eye, a trigger event occurs when the object of interest is sufficiently within its view and the photo eye signals a trigger to the camera to acquire the current image and pass it to inspection by the vision system. In the above-described native-image-triggering camera assembly, and as described further below, a trigger event involving an “internal” trigger can entail an acquired image to satisfy various criteria. If the criteria are satisfied, the trigger event passes the acquired image (which generated the event), or another subsequent image to inspection.
By way of general example, an image-acquisition-based trigger mode as implemented in prior systems typically operates to capture images continuously (meaning in a continuing sequence for some period of time—that sequence potentially skipping frames or acquiring every available frame), while attempting to satisfy a predetermined “trigger logic” (i.e. the rules and criteria that cause a trigger event). This trigger logic is designed to pass when an object enters sufficiently/fully into the vision system's field of view. Once the trigger logic passes, the vision system then transmits the acquired image to another logic process to perform the main inspection and return/output the associated inspection results.
Other potential disadvantages of internal (within the vision system) and external (using a separate camera or other monitoring device) trigger logic using image acquisition is that the acquisition counts between the vision system and external monitoring devices become inaccurate. This can occur, for example when image acquisitions that trigger the trigger logic are not counted as main inspection triggers and theses two counts fall out of synchronization. Also, there are disadvantages resulting from gating of output inspection results (for example via discrete I/O) when running the trigger logic. Other complications can also arise in using an image-acquisition-based trigger logic (e.g. looping, changing trigger modes, and enabling/disabling trigger and inspection logic).
It is therefore desirable to provide a trigger functionality that is readily configurable based on a variety of variable parameters via a user interface. This trigger functionality should avoid common disadvantages of complexity and loss of synchronization with inspection processes.